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Abstract  -  We  specify  duty  cycles  of  a  Ballistic  Missile 
Defense  (BMD)  command  and  control  application  by 
decorating  the  Business  Process  Execution  Language 
(BPEL)  with  Quality  of  Service  (QoS),  Measures  of 

Performance  (MoP),  Measures  of  Effectiveness  (MoE) 
and  Measures  of  Merit  (MoM)  metrics. 
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1  Introduction 

Command,  Control,  Communication,  Intelligence, 

Surveillance,  and  Reconnaissance  (C4ISR)  applications 
require  making  decisions  based  on  situational  awareness 
created  by  fusing  sensory  information  collected  from 
independently  maintained  sources.  Having  a  command  and 
control  (C2)  structure  that  respects  the  autonomy  of  basic 
services  facilitates  the  flexibility  to  dynamically  negotiate 
and  adjust  to  changes  in  the  battle  space  while  maintaining 
the  continuity  of  the  overall  operations  and  deployment 
readiness.  In  this  paper  we  develop  such  a  framework  to 
thwart  threats  from  ballistic  missiles  by  using  a  three-tiered 
C2  structure.  This  sits  well  with  the  U.S.  DoD’s  objective 
of  adopting  Service  Oriented  Architecture  (SOA)  in  which 
the  master  orchestrator  provides  a  service  by  composing 
the  services  of  the  autonomously  functioning  sub-services. 
The  continuity  of  orchestrated  operations  is  modeled  by 
duty  cycles,  with  each  duty  cycle  reacting  to 
environmental  changes.  The  orchestrator  provides  the 
required  quality  of  service  (QoS)  -  which  includes 
timeliness  as  one  aspect  [1].  As  shown  in  this  paper,  a 
flexible  QoS-sensitive  SOA  suffices  to  specify  and 
implement  stated  C4ISR  requirements. 

The  DoD  mandated  the  basic  web  services  (WS) 
framework  standards  for  use  in  Enterprise  Resource 
Planning  (ERP)  software  packages,  but  has  not  mandated 
the  standards  for  use  in  the  Global  Information  Grid  (GIG) 
as  the  standards  fall  short  in  meeting  GIG  security  and 
authorization  requirements  [2].  The  basic  WS  framework 
standards  include  what  are  commonly  referred  to  as  the 
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core  web  service  development  standards;  Web  Services 
Description  Language  (WSDL),  SOAP,  and  Universal 
Description,  Discovery  and  Integration  (UDDI).  Although 
the  core  WS  have  been  applied  successfully  by  industry  in 
business  systems,  as  Birman  et  al.  claim  [3],  they  fall  short 
of  C4ISR  needs  due  to  the  lack  of  support  for  time-critical 
events.  Consequently,  in  this  study  we  decorate  BPEL 
specified  duty  cycles  with  QoS,  specifically  timeliness 
attributes,  MoP  and  MoE  specifications,  with  the  hope  that 
a  SOA  satisfying  the  need  articulated  by  Birman  et  al.  can 
implement  our  design.  The  rest  of  the  paper  is  organized  as 
follows.  Section  2  specifies  use  cases  for  a  ballistic  missile 
defense  system.  Section  3  presents  an  overview  of 
conventional  C2  and  possible  execution  using  WS  and 
specifies  a  C2  family  of  WS  using  WSDL,  and  Section  4 
presents  their  process  integration  using  BPEL.  Section  5 
discusses  the  evolution  of  the  Operations  Order.  Section  6 
concludes  the  paper. 


2  BMD  C2 

The  objective  of  the  Missile  Defense  Agency’s  (MDA) 
Advanced  Battle  Manager  (ABM)  of  the  Ballistic  Missile 
Defense  System  (BMDS)  [5]  is  to  provide  an  integrated, 
layered  defense  from  ballistic  missiles  of  all  ranges  in  all 
phases  of  their  flight.  At  a  high  level,  the  BMDS  consists 
of  an  integrated  C2,  Battle  Management  (BM),  and 
Communications  (collectively  known  as  C2BMC),  and 
weapons  and  sensors.  Weapons  and  sensors  are  capable  of 
engaging  and  sensing  many  different  threat  missiles 
through  different  phases  of  their  flight:  boost,  mid-course 
and  terminal.  The  C2  component  is  responsible  for 
creating  and  distributing  the  operations  orders  (OPORD), 
that  essentially  provides  initial  weapons,  and  sensor 
locations,  their  orientations,  and  their  responsibilities 
within  the  plan  while  the  BM  executes  the  battle  according 
to  the  OPORD  and  the  responses  from  sensory  inputs. 

Wijesekera,  Michael  and  Nerode  [4]  use  three  kinds  of 
agents  to  model  BMDS  C2:  the  strategic  commander 
agent  (SCA),  regional  commander  agent  (RCA),  and  the 
tactical  commander  agent  (TCA).  Each  battle  manager 
assumes  one  of  these  roles.  A  hierarchical  command 
structure  in  [4]  consists  of  SC  As  at  the  top  of  the  C2 
structure  that  share  information  horizontally  between  them. 
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Each  SC  A  manages  vertically  down  the  chain  to  its 
assigned  RCA’s  and  with  any  assigned  sensors  and 
weapons  in  the  sensors  and  weapons  nets.  Continuing 
down  the  C2  structure  the  individual  RCA’s  manage  and 
communicate  with  their  assigned  TCAs  and  any  assigned 
weapons  and  sensors  in  the  weapons  and  sensors  nets. 
Finally,  each  TCA  manages  and  communicates  with  its 
assigned  weapons  and  sensors  within  the  sensors  and 
weapons  nets.  While  information  travels  up  and  down  the 
C2  structure,  most  down-flows  are  commands  and  most 
up-flows  are  status  reports. 

2.1  Assumptions 

1.  Operations  Orders  (OPORDs)  have  been  issued  by  all 
agents  and  each  agent  has  established  its  defenses. 
This  implies  that  all  weapon  and  sensor  systems  for  the 
entire  BMDS  are  positioned  to  defend  against  the  most 
likely  threat  missile  attack  according  to  the  OPORD 
intelligence  estimate;  weapon  systems  have  specific 
orientations  ready  to  launch  and  sensors  are  in 
surveillance  mode. 

2.  Given  that  the  threat  attacks  according  to  the  OPORD 
intelligence  estimate,  we  assume  the  weapon  and 
sensor  systems  execute  the  plan  autonomously  with 
little  or  no  interference  from  the  command  agents. 

3.  In  our  scenario  the  threat  does  not  attack  according  to 
the  intelligence  estimate  and  SCA1,  RCA2  and 
assigned  TCAs  must  manage  the  initial  attack  to  defeat 
the  threats. 

2.2  Scenario  execution 

Our  scenario  shown  in  Figure  1  proceeds  as  follows. 
RCA2’s  organic  sensor  and  BM  determine  that  three 
separate  threat  missiles  are  inbound  and  predicted  to  hit  a 
high-priority  asset  on  its  Prioritized  Defended  Asset  Fist 
(PDAF).  According  to  the  OPORD  the  terminal-defense 
mission  for  the  asset  being  attacked  is  assigned  to  TCA22 
and  the  midcourse  defense  of  the  asset  is  assigned  to 
TCA21.  However,  based  on  the  OPORD  Intel  annex  most 
resources  in  SCAl’s  area  of  operation  are  oriented  on  the 
enemy’s  likely  air  avenue  of  attack,  depicted  by  the  large 
dotted  arrow  and  labeled  as  such  in  the  figure.  Therefore, 
reorienting  of  resources  within  RCA2’s  area  of  operation 
is  necessary  to  negate  the  threats.  RCA2  concurrently 
sends  a  contact  message  to  SCA1  requesting  permission  to 
reorient  resources  and  engage  the  threats,  in  addition  to 
sending  a  be-prepared-to-launch  order  to  TCA21  and 
TCA22. 


Figure  1  BMDS  Scenario 

The  messages  being  exchanged  include  the  individual 
threat  tracks  and  values  for  specific  QoS  attributes,  MOP, 
and  MOE  necessary  to  ensure  the  threats  are  engaged  prior 
to  reaching  their  keep-out  ranges.  In  this  scenario  RCA2 
has  two  MOEs  associated  with  it:  (i)  survivability,  defined 
as  the  fraction  of  defended  assets  that  survive  the  attack 
and  (ii)  the  probability  that  the  interceptor  kills  the  threat 
target  given  that  it  arrives  in  time.  The  MOP  associated 
with  RCA2  is  Time-on-Target;  the  time  remaining  for  any 
weapon  system  to  launch  an  interceptor.  This  is  included 
to  give  subordinates  an  upper  bound  on  time  to  engage 
with  the  appropriate  shot  doctrine. 

TCA21  receives  the  be-prepared  order  (to  launch)  and 
steps  into  the  kill  chain  cycle  at  the  assign  weapon  task. 
Using  the  track  information  from  RCA2,  TCA21 
determines  the  appropriate  weapon  systems  with  which  to 
engage  the  threat  missiles,  builds  an  engagement  plan,  and 
issues  a  be-prepared  order  to  the  appropriate  weapons  and 
sensors.  Eikewise,  TCA22  receives  its  be-prepared  order 
to  launch,  but  its  launch  is  contingent  on  the  threat 
reaching  the  keep-out  range.  TCA22  also  steps  into  the 
kill  chain  cycle  at  the  assign  weapons  task  and  issues  be- 
prepared  missions  to  its  associated  weapons  and  sensors. 

Upon  receiving  SCAl’s  response  message  to  launch, 
RCA2  issues  a  message  to  the  TCAs  to  execute  the  be- 
prepared  missions  sent  earlier.  TCAs  21  and  22  use  the 
MOEs  and  MOP  from  RCA2  to  guide  the  selection  of  the 
services  required  to  complete  the  weapons  assignment, 
engagement,  and  assess  kill  tasks  of  the  kill  chain.  We 
show  this  in  detail  in  subsequent  sections,  but  first  we 
describe  the  scenario  for  each  of  the  agents:  SCA1,  RCA2, 
and  TCAs  21  and  22.  We  show,  in  use  case  (a  technique 
for  describing  how  to  achieve  a  goal  or  task)  format,  the 
kill  chain  tasks  performed  by  each  agent  in  our  scenario. 
Figure  2  shows  the  process  logic  a  BM  executes  upon 
receiving  a  track  list 
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Use  Case  1:  Detect 

Goal  in  Context:  Identify  threats  from  a  list  of  reported 
sensor  tracks 

Scope  &  Level:  A  primary  task  of  the  battle  Manager 
Preconditions:  Battle  manager  has  been  initialized 
Success  End  Condition:  Correctly  identify  threat  object. 
Failed  End  Condition:  Fails  to  identify  threat  missile. 
Primary  Actor:  Battle  Manager 
Trigger:  Receive  track  list  from  a  sensor 
MAIN  SUCCESS  SCENARIO 

7.  Receive  Track  List  message 

2 .  Verifies  source  of  message 

3.  Validate  request  parameters 

4.  Associates  Track  List 

5.  Correlates  Track  List 

6.  Returns  a  threat  list 


Figure  2:  Detect 

Figure  3  shows  the  execution  logic  of  a  BM  upon  receipt 
of  a  track  list  from  a  sensor  in  its  C2  structure. 

Use  Case  2:  Track 

Goal  in  Context:  Return  a  launch  quality  threat  track 

Scope  &  Level:  A  primary  task  of  the  battle  Manager 

Preconditions:  Detect  Task  complete 

Success  End  Condition:  Produces  fire  quality  tracks 

Failed  End  Condition:  Fails  to  produce  fire  quality  track 

Primary  Actor:  Battle  Manager 

Trigger:  Receive  a  threat  list 

MAIN  SUCCESS  SCENARIO 

7.  Receive  Threat  List  message 

2.  Verifies  source  of  message 

3.  Validate  request  parameters 

4.  Fuse  threat  List 

5.  Calculate  IPP  for  threats 

6.  Calculate  Aim  Point  for  threats 

7.  Calculate  time  available  to  kill  threats 

8.  Calculate  QoS,  MOP,  MOE  requirements 

9.  Returns  a  threat  list,  QoS,  MOP,  MOE 


Figure  3:  Track 

Figure  4  shows  the  process  logic  a  BM  executes  upon 
receiving  a  threat  track  list. 


Use  Case  3:  Assign  Weapon 

Goal  in  Context:  Identify  the  best  weapon  system  to 
destroy  the  threat 

Scope  &  Level:  A  primary  task  of  a  BM 
Preconditions:  Detect  and  track  tasks  in  the  kill  chain  has 
successfully  completed 

Success  End  Condition:  Identify  weapon  to  destroy  the 
identified  threat  missiles. 

Failed  End  Condition:  A  weapon  system  is  not  identified 

Primary  Actor:  BM 

Trigger:  Receive  a  weapons  assignment  message 
MAIN  SUCCESS  SCENARIO 
7.  Receive  Launch  message 

2.  Verifies  source  of  message 

3.  Validate  request  parameters 

4.  Monitor  QoS  requirements 

5.  Identify  available  resources 

6.  Target  weapon  pairing 

7.  Return  result 


Figure  4:  Assign  Weapon 

Figure  5  shows  the  process  logic  a  BM  executes  upon 
receiving  a  threat  track  list  with  weapons  assignment 
solution. 


Use  Case  4:  Engage 

Goal  in  Context:  Assigned  weapon  launches  interceptor 
Scope  &  Level:  This  is  a  primary  task  of  the  TCA 
Preconditions:  TCA  has  been  initialized 
Success  End  Condition:  TCA  assigns  Launch  to 
appropriate  (based  on  message)  weapon  or  responds  to 
caller  that  no  weapon  is  available 
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Failed  End  Condition:  TCA  fails  to  assign  weapon  or 

report  that  there  is  a  problem  in  launching  to  caller 

Primary  Actor:  TCA 

Trigger:  Receive  Launch  from  superior 

MAIN  SUCCESS  SCENARIO 

7.  Receive  Launch  message 

2.  Verifies  source  of  message 

3.  Validate  request  parameters 

4.  Monitor  QoS  Requirements 

5.  Build  engagement  plan 

6.  Send  plan 

7.  Monitor  QoS  Requirements 


Figure  5:  Engage 

Figure  6  shows  the  process  logic  a  BM  executes  upon 
receiving  an  assess  kill  message.  Figure  7  shows  the 
process  logic  a  BM  executes  upon  first  receiving  an 
initialization  message  followed  some  time  later  by  an 
assign  weapon  message. 


MAIN  SUCCESS  SCENARIO 

7.  Receive  Launch  message 

2.  Verifies  source  of  message 

3.  Validate  request  parameters 

4.  Monitor  QoS  Requirements 

5.  Report  engagement  result 

6.  Return  result  to  caller 


Figure  6:  Asses  Kill 

In  addition  to  the  possibility  of  a  weapons  system  missing 
a  target  there  exists  the  possibility  that  a  BM  has  no 
weapons  systems  available  for  assignment.  In  this 
situation  the  BM  alerts  its  superior  so  that  an  alternative 
BM  can  be  chosen  for  the  mission;  it  is  customary  in 
military  operations  to  have  this  built  in  to  the  plan  and 
therefore  the  engage  task  would  have  planned  to  have  a 
number  of  weapons  systems  and  BM’s  on  stand-by  (be 
prepared  mission)  for  these  type  of  circumstances.  After 
completion  of  the  kill  assessment  the  duty  cycle  repeats. 


Assess 

Kill 


Receive 
T rack  List 


Conventional  battle  managers  follow  a  duty  cycle 
commonly  referred  to  as  a  kill  chain  [5]  consisting  of  the 
following  tasks:  detect,  track,  assign  weapon,  engage,  and 
assess  kill.  The  kill  chain  begins  when  a  sensor  reports  an 
object  to  a  BM  agent.  The  agent  continues  to  track  the 
object  while  determining  if  the  object  poses  a  threat,  and  if 
the  object  does  pose  a  threat,  assigns  an  available 
interceptor  to  destroy  it.  After  the  firing  of  the  interceptor, 
the  BM  agent  continues  to  monitor  and  assess  the 
engagement;  if  the  initial  interceptor  fails  to  destroy  the 
threat  missile  and  the  shot  doctrine  used  dictates  a  second 
shot  (e.g.  shoot-look-shoot  policy)  the  weapon  system  re¬ 
engages  the  threat  with  updated  target  information. 


Use  Case  5:  Assess  Kill 

Goal  in  Context:  Determine  correctly  the  result  of  an 
engagement. 

Scope  &  Level:  A  primary  task  of  the  TCA 
Preconditions:  TCA  has  been  initialized 
Success  End  Condition:  TCA  returns  a  correct 

assessment  of  an  engagement 

Failed  End  Condition:  TCA  fails  to  return  a  correct 

assessment  of  an  engagement 

Primary  Actor:  TCA 

Trigger:  Receive  Launch  from  superior 


Figure  7:  Assign  Weapon  Process 


3  Web  Services  for  battle  management 

We  now  specify  a  conventional  BM  as  a  service  in  a 
SOA  by  specifying  the  kill  chain  as  a  periodic  process  that 
is  the  main  orchestrator  of  a  BPEL  process  decorated  with 
QoS,  MOE,  and  MOP  extensions  specified  in  [14]. 
Selecting  the  participating  partner  services  of  the  main  kill 
chain  is  based  on  the  client  QoS  and  MOE  parameters. 
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1.  Target  Association  Service  (TA):  Begins  the  kill 
chain  when  it  receives  a  list  of  potential  tracks  of  the  threat 
missile  from  the  sensor  net  as  reported  by  radars,  using  a 
track  association  algorithm  to  identify  the  track  objects 
reported  by  these  sensors. 

2.  Track  Correlation  Service  (TC):  Uses  a  correlation 
algorithm  to  compare  the  reduced  track  list  against  a 
known  threat  database  to  classify  the  missile.  If  the  track 
object  does  not  match,  but  observed  measurements  (e.g.  its 
velocity  is  in  the  range  of  a  ballistic  missile)  makes  it 
suspicious,  it  is  marked  suspicious  and  assigned  to 
additional  sensors  for  observation.  All  others  are  logged 
for  offline  analysis. 

3.  Track  Fusion  Service  (TF):  Track  objects  gathered 
thus  far  are  used  to  create  an  enhanced  description. 

4.  Impact  Prediction  Point  Service  (IPP):  Predicts  the 
impact  point  of  the  threat  missile. 

5.  Aim  Point  Predictor  Service  (APP):  Computes  an 
aiming  point  for  each  track  object. 

6.  Target  Weapon  Pairing  Service  (TWP):  Computes 
the  most  appropriate  weapons  systems  to  engage  the 
threats. 

7.  Engagement  Planner  Service  (EP):  Output  from 
TWP  and  information  from  the  Operations  Plan  (OPLAN) 
is  used  by  EP  to  design,  issue,  and  notify  all  parties  of  the 
plan  to  destroy  the  threat  missiles. 

8.  Assess  Kill  Service  (AK):  Assess  battle  damage  using 
the  sensor  net  to  complete  the  entire  kill  chain  cycle. 

The  detect  task  is  composed  of  the  TA  and  TC  services. 
The  track  task  is  composed  of  TF,  IPP,  and  APP  services. 
The  assign  weapons  task  is  composed  of  TWP  service. 
Engage  task  is  composed  of  an  EP  service  and  the  assess 
kill  task  consists  of  the  AK  service.  We  list  the  QoS,  MoP 
and  MoE  parameters  of  each  of  the  eight  services  and  the 
five  tasks  in  Table  1.  Figure  9  shows  the  detect  task  as  a 
composition  of  the  selected  TA  service  and  the  TC  service. 

<portType  name="DetectPT"> 

<operation  name="DetectProcess"> 

<mopList> 

<mop  name="ExecutionTime"  value- T  2 sec '7> 

<mop  name-' Accuracy"  value- '.998 '7> 

</mopList> 

<moeList> 

<moe  name- ’DetectTargetlnBOOST"  value- 'nuH7> 
</moeList> 

<input  message- 'tns:DetectMsgRequesf7> 

<output  message- ftns:DetectMsgResponse'7> 

<operation> 

</portType> 

Figure  8:  Detect  Composition  WSDL 
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mission  to 

destroy  threat 
and  monitor 
BDA 

Assess  Kill 

Availability 

Execution 

Assign  best 

Reliability 

Time 

Accuracy 

sensor  to 

conduct  BDA 

Track 

Availability 

Execution 

Identify  and 

Association 

Reliability 

Time 

assoc  correct 

(TA) 

Accuracy 

number  of 

tracks  with 
its  source 

Track 

Availability 

Execution 

ID  track 

Correlation 

Reliability 

Time 

Objects  as 

(TC) 

Accuracy 

threat 

Track  Fusion 

Availability 

Execution 

Enhance 

(TF) 

Reliability 

Time 

Accuracy 

threat  object 
by  fusing 

data  from 

multiple 
sensors 

Impact  Point 

Availability 

Execution 

Determine 

Prediction 

Reliability 

Time 

IPP  within  10 

(ipp) 

Accuracy 

m2 

Aim  Point 

Availability 

Execution 

Determine 

Prediction 

Reliability 

Time 

Aim  Point 

(APP) 

Accuracy 

within  100 
cm2 

Target 

Availability 

Execution 

Best  weapon 

Weapon 

Pairing  (TWP) 

Reliability 

Time 

Accuracy 

to  kill  target 

Engage 

Availability 

Execution 

Best  plan  to 

Planner 

Reliability 

Time 

destroy  target 

(EPS) 

Accuracy 

prior  to  keep 
out  range 

Assess 

Availability 

Execution 

Best  sensor 

Kill 

Reliability 

Time 

to  conduct 

(AK) 

Accuracy 

BDA 

Table  1:  QoS,  MOP,  MOE 


<portType  name- ’TrackAssocPT"> 

<operation  name- ’AssocTrackList"> 

<mopList> 

<mop  name- ’ExecutionTime"  value- ’5sec"/> 
<mop  name- ’ Accuracy”  value-’. 999 7> 
</mopList> 

<moeList> 

<moe  name- ’AssocTrackToSource"  value- ’null7> 
</moeList> 
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<input  message- ’tns:TrackAssocMsgRequest7> 

<output  message=”tns:TrackAssocMsgResponse”/> 
<operation> 

</portType> 

Figure  9:  Track  Association  WSDL 

<portType  name- 'TrackCorrPT”> 

<operation  name=”CorrTrackList’’> 

<mopList> 

<mop  name- ’ExecutionTime”  value- ’5sec”/> 

<mop  name-’ Accuracy”  value-’. 999 7> 

</mopList> 

<moeList> 

<moe  name- ’IDThreatGivenThreat’ ’  value=’’NULL”/> 
</moeList> 

<input  message- ’tns:TrackCorrMsgRequest'7> 

<output  message-’tns:TrackCorrMsgResponse”/> 
<operation> 

</portType> 

Figure  10:  Track  Correlation  WSDL 

Finally,  we  show  the  WSDL  of  a  complete  kill  chain  that 
is  composed  of  the  higher  level  tasks  detect,  track,  assign 
weapon,  engage,  and  assess  kill  which  are  themselves 
composed  of  the  atomic  level  services  described  earlier. 

<portType  name- 'KillChainPT”> 

<operation  name- ’killThreat”> 

<mopList> 

<mop  name-’ ExecutionTime”  value=”27sec”/> 

<mop  name-’Accuracy”  value- ’.95 870”/> 

</mopList> 

<moeList> 

<moe  name- ’DefendAsset”  value=”NULL”/> 
</moeList> 

<input  message=”tns:KillChainMsgRequest”/> 

<output  message- ’tns:KillChainMsgResponse’7> 

<fault  name=”Fail”  message=”FailNotice:”/> 
<operation> 

</portType> 

Figure  11:  Kill  Chain  WSDL 

In  each  composition  instance  execution  time  was  the  MOP 
used  to  select  a  service. 

One  of  the  two  extensions  necessary  to  orchestrate  C4ISR 
is  the  need  for  QoS  sensitivity,  for  which  we  use  the 
lightweight  Q-WSDL  extension  in  [13].  In  particular,  we 
use  the  Operational  Latency  class  where  execution  times 
of  every  operation  are  specified.  The  second  is  the  use  of 
the  shadow  pattern  of  [11]  that  specifies  exception 
handling.  We  use  message  types,  messages  and  services 
with  the  standard  notations  of  for  zero  or  more 
repetitions,  ‘?’  for  zero  or  one  repetitions,  and  ‘+’  for  one 
or  more  repetitions. 


3.1  Message  Types 

Tables  2  and  3  list  sample  basic  and  complex  WSDL  data 
types  [9]  used  in  exchanged  messages. 


Type  Name 

Primitive 

Example 

myld 

Long  Int 

123456789245 

sensorlD 

Long  Int 

454656736363 

Availability 

Boolean 

Yes/No 

weaponName 

String 

THHAD,  AEGIS,  .. 

sensorName 

String 

FBX,  SBX,  ... 

ammo  Status 

String 

Green,  Red,  Yellow 

timeToEngage 

Duration 

P0y0m0dt0h0m3  s 

dateTimeGroup 

DateTime 

2007-05- 

3 1 T1 3 :20:00-05 :00 

Hostile 

Boolean 

Yes/No 

Latitude 

Long  Int 

765468642222 

Longitude 

Long  Int 

367463823982 

Velocity 

Long  Int 

645646455467 

Acceleration 

Long  Int 

832678326864 

Table  2:  Basic  types  of  message  elements 


Type  Name 

Type  Structure 

Example 

OPORD 

xmlns :  OPORD- ’http  ://swe 

opord20080 

.nps.edu/BMDS/OPORD 

129 

Track 

XmlN  S=URI#trackType 

Track 

Structure 

Weapon 

XmlN  S=URI#weaponType 

Weapon 

structure 

Sensor 

XmlNS=URI#sensorType 

Sensors 

structure 

Sea 

XmlN  S=URI#scaType 

sea  structure 

Tea 

XmlN  S=URI#tcaType 

tea  structure 

QoS 

XM1N  S=URI#qwsdl :  opera 

QoS 

tionType  [13] 

Structure 

Bond 

XmlN  S=URI#T  ime 

$3.5  Cred  1 

Turing  test 

Image 

10101. .01 

Table  3:  Complex  types  of  message  elements 

3.2  Messages 

A  sample,  assignWeaponMsg,  is  shown  in  Listing  1.  Other 
domain- specific  messages  are  listed  in  Table  4  below  with 
their  definitions.  Similarly  Listings  2  and  3  show  other 
control  messages.  Finally,  Tables  5  and  6  describe  some 
services  provided  by  the  TCA  and  other  third  parties. 

1.  <message  name- ’AssignWeaponMsg’’> 

2.  <part  name- ’ID’’  element- ’message  ID”/> 

3.  <part name- ’Track”  element-’ string”/> 

4.  <part  name=”OPORD”  element=”OPORD’7> 

5.  <part  name- ’DATE”  element- ’Time”/> 

6.  <part name-’QOS"  element- ’QoSType”/> 

7.  <part  name- ’surety”  element=”Bond’7> 

8.  <part  name- ’Ack”  element=”wantAck’7> 

9.  <part  name=”Sign”  element=”PKISignature/>* 

10.  <part  name-’RTT  reply”  element=”Turing  test 
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11.  </message> 

Listing  1:  WSDL  AssignWeaponMsg 


Message  Type 
detectMsg 

trackMsg 

assignWeaponMsg 

engageMsg 

assessKillMsg 

launchlnterceptorMsg 

cancelLaunchMsg 

weaponHSMsg 


Utility 

Kill  chain  task  to  associate 
tracks  with  a  source  and 
determine  if  the  track  is  a 
threat 

Kill  chain  task  to  fuse  track 
information,  determine  the 
threat  impact  point,  and 
calculate  an  aim  point 
Kill  chain  task  to  assign 
the  most  appropriate 
weapon  to  negate  a  know 
threat 

Kill  chain  task  to  build  an 
engagement  plan  to  defeat 
a  threat 

Kill  chain  task  to  monitor 
engagement  and  report 
Battle  Damage  Assessment 
Command  to  Launch  an 
interceptor 

Command  to  cancel  a 
previous  launch  command 
Command  to  return  the 
health  and  status  of  all 
weapons 


Table  4:  Types  of  Messages 


1 .  <message  name="initializeBMMsg"> 

2.  <part  name- 'id"  element="long"/> 

3.  <part  name=”OPORDO  1293 12008” 
element=”OPORD” 

4.  </message> 

5.  <message  name="deRequisitionMsg"> 

6.  <part name- 'ID"  element-' long"/> 

7.  </message> 

Listing  2:  WSDL  Application  Data 

1 .  <message  name="F  ailNotice"> 

2.  <part name-'Date"  element-' dateTime'7> 

3.  <part  name="ID"  element- 'long'7> 

4.  <part name-'ERROR"  element="string'7> 

5.  <part name="Sign_PKI"  element-' string'7> 

6.  </message> 

7.  <message  name- 'LaunchInterceptorReciepf'> 

8.  <part name-'DATE"  element- 'dateTime'7> 

9.  <part name="ID"  element-' long'7> 

10.  <part  name- 'comment"  element="string'7> 

1 1 .  <part  name="Sign_PKI"  element- 'string'7> 

12.  </message> 

Listing  3:  WSDL  Control  Data 


1.  <portType  name="assignWeaponPT"> 

2.  <operation  name="assignWeapon"> 

3.  <input  message="tns:assignWeaponMsg"/> 

4.  <output  message- 'tns:assignWeaponReciept'7> 

5.  <faultname="faultassignWeapon  "message="tns:FailNotice"  /  > 

6.  </operation> 

7.  </portType> 

Table  5:  WSDL  Port  Type  Specs  for  BM  services 

1 .  <portType  name="monitorServicePT"> 

2.  <operation  name- 'monitor"> 

3.  <input  message="tns:startMsg"/> 

4.  <output  message="tns:StartNotificationMsg"/> 

5.  <fault  name- 'monitorfault" 

6.  message- 'tns:FailNotice'7> 

7.  </operation> 

8.  </portType> 

9.  <portType  name="timerPT"> 

1 0 .  <operation  name-'  startT imer "> 

1 1 .  <: input  message="tns:startMsg"/> 

12.  </operation> 

13.  </portType> 

Table  6:  WSDL  Port  Type  for  C2  Third  Party  Services 

3.3  Operations  Order  (OPORD) 

An  OPORD  is,  “a  directive  issued  by  a  commander  to 
subordinate  commanders  for  the  purpose  of  effecting  the 
coordinated  execution  of  an  operation”  [16].  The  OPORD 
is  a  vital  document  in  ballistic  missile  defense  as  it 
explains  in  detail  the  responsibilities  of  all  systems.  The 
OPORD,  at  a  minimum,  contains  unit  task  organization 
and  the  five  paragraphs  of  (1)  Situation  (2)  Mission  (3) 
Execution  (4)  and  Service  Support  (5)  Command  and 
Signal. 

In  traditional  land  warfare  combat  commanders  issue  their 
orders  to  subordinate  commanders  who  in  turn  prepare  and 
issue  orders  to  their  subordinates  until  each  combatant  in 
every  unit  knows  his  or  her  mission  and  the  mission  of 
those  two  levels  up  the  chain  of  command.  The  initial 
OPORD  of  nearly  all  campaigns  are  routinely  more 
detailed  and  well  thought  out  than  subsequent  OPORDs. 
This  tendency  is  a  direct  reflection  of  the  amount  of  time 
available  to  plan  prior  to  hostilities  beginning.  For  the 
initial  order,  units  may  have  days,  weeks,  and  even  months 
to  plan  and  issue  the  orders.  Once  hostilities  begin,  the 
time  to  plan  generally  decreases  and  makes  the 
development,  issuance  and  coordination  of  plans  more 
difficult,  in  addition  to  reducing  timelines  to  days  or  hours. 

In  missile  defense  the  timelines  are  significantly  shorter 
than  traditional  land  warfare  combat  scenarios  discussed 
above.  In  the  missile  defense  domain  timelines  can  be  in 
the  range  of  several  minutes  to  as  little  as  30  seconds. 
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With  such  short  timelines  we  look  to  perform  autonomous 
execution  of  missile  defense  engagements  where  we 
remove  the  human  from  the  loop.  For  this  reason  the 
OPORD  must  be  designed  to  be  read  and  “understood”  by 
computers;  we  accomplish  this  in  our  case  study  by 
constructing  our  OPORDs  using  the  Resource  Description 
Framework  (RDF)[15].  RDF  is  a  W3C  Recommendation 
for  describing  Web  resources  and  is  designed  to  be  read  by 
computers.  We  show  in  Table  7  below  our  OPORD 
written  in  RDF/XML  for  the  scenario  described  above  and 
pictured  in  Figure  1.  The  RDF  provides  the  means  to 
describe  the  complex  structure  of  the  OPORD  so  that  it 
can  be  understood  by  the  participating  BMs.  In  Table  7, 
lines  40,  44,  48,  52,  and  56  show  the  five  minimum 
essential  paragraphs  of  an  OPORD  as  defined  in  [16]. 
Each  of  the  five  paragraphs  is  a  property  that  has  a 
reference  to  a  resource  containing  information  about  the 
particular  property.  As  an  example  we  show  at  line  47  the 
property  OPORD  MISSION  has  a  reference  to  a  resource 
containing  information  about  the  TCA’s  MISSION;  the 
text  of  an  actual  mission  for  TCA22  is  in  bold.  It  is  certain 
that  some  of  the  other  paragraphs  have  sub-graphs  and 
each  of  those  can  be  defined  by  a  value  or  as  in  the  case  of 
the  OPORD  MISSION  a  reference  to  another  resource. 


7.  <?xml  version-’ 1.0"?> 

2.  <rdf:RDF  xmlns:rdf= 

3.  '’http://www.w3.Org/1999/02/22-rdf-syntax-ns#" 

4.  xmlns : rdfs-’http ://www. w3 . org/2000/0 1 /rdf- 

schema#" 

5.  xmlns:OPORD="http://swe.nps.edu/BMDS/OPORD 

#"> 

//The  rdf  description  element  that  describes  our 

resource 

//  OPORD 

6.  <rdf:Description  rdf:about= 

7.  "http://swe.nps.edu/BMDS/OPORD/opord20080129 

"> 

8.  <OPORD:classification> 

9.  <rdf:Alt> 

10.  <rdf:li>UNCLASS</rdf:li> 

11.  </rdf:Alt> 

12.  </OPORD:classification> 

13.  <OPORD:CopyNumOfNumCopies>l  of  100 

14.  </OPORD:CopyNumOfNumCopies> 

1 5.  <OPORD : issuingHQ>TCA2 1  </OPORD :  issuingHQ 

> 

16.  <OPORD:placeofIssue>452143</OPORD:placeofIs 

sue> 

1 7.  <OPORD : DT GS ignature>0 1 2920080 1 00 

18.  </OPORD:DTGSignature> 

19.  <OPORD:MsgRefNum>0 12920080245 

20.  </OPORD:MsgRefNum> 

27.  <OPORD:OrderNumber>0 1292008-45 

22.  </OPORD:OrderNumber> 

23.  <OPORD:codeName>Butkus</OPORD:codeName> 


24.  <OPORD:references> 

25.  <rdf:Seq> 

//Reference  to  the  SCA’s  Initiating  OPORD  Code 
Name  Lambert 

26.  <rdf:li  rdf:resource= 

2 7.  "http://swe.nps.edu/BMDS/documents/OPORD/Lam 

bert"> 

28.  </rdf:li> 

//Reference  to  the  RCA2’s  Initiating  OPORD  Code 
Name  HAM 

29.  <rdf:li  rdf:resource= 

30.  "http://swe.nps.edu/BMDS/documents/OPORD/Ham 

"> 

31.  </rdf:li> 

32.  </rdf:Seq> 

33.  </OPORD:references> 

34.  <OPORD:timeZoneUsed>ZULU 

35.  </OPORD:timeZoneUsed> 

//Task  Organization  is  defined  by  the  resource  URI 
below 

36.  <OPORD:taskOrginization 

37.  rdf:resource= 

38.  "http://swe.nps.edu/BMDS/OPORD/opord20080129 

39.  /Annex AT askO  "x/OPORD : taskOrginization> 

//The  first  of  the  minimum  essetial  elements  of  the 
five 

//Paragraph  operations  order;  SITUATION 

40.  OPORD: SITUATION 

41.  rdf:resource= 

42.  "http://swe.nps.edu/BMDS/OPORD/opord20080129 

43.  /Situation"></ OPORD :  SITU ATION> 

//The  second  of  the  minimum  essetial  elements  of  the 
five 

//Paragraph  operations  order;  MISSION 

44.  OPORDMISSION 

//  The  URI  at  line  46  is  a  reference  to  the  document 
that 

//contains  the  following  mission  statement  for  this 
OPORD 

//MISSION:  060004282008  (Z)  TCA22  forces  Defend 
//assets  according  to  the  Priority  Defended  Assets 
List 

//(PDAL)  against  anticipated  ballistic  missile  attacks 
//within  region. 

45.  rdf:resource= 

46.  "http://swe.nps.edu/BMDS/OPORD/opord200801 

29 

//  The  URI  at  line  48  is  a  reference  to  the  document 
that 

//contains  the  next  Higher  level  of  commands  (RCA2 
in 

this  scenario)  mission  statement  for  this  OPORD 

//MISSION:  060004282008  (Z)  RCA2  forces  Defend 
//assets  according  to  the  Priority  Defended  Assets 
List 
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//(PDAL)  against  anticipated  ballistic  missile  attacks 
//within  region. 

47.  <OPORD :HIGHERMIS SION 

48.  rdf:resource=  "  http://swe.nps.edu/BMDS/documents 
/OPORD/Ham.MISSION 

//The  third  of  the  minimum  essetial  elements  of  the 
five 

//Paragraph  operations  order;  EXECUTION 

49.  <OPORD: EXECUTION 

50.  rdf:resource= 

51.  '’http://swe.nps.edu/BMDS/OPORD/opord20080129 

52.  /Execution"></OPORD:EXECUTION> 

//The  fourth  of  the  minimum  essetial  elements  of  the 
five 

//Paragraph  operations  order;  SERVICE 
SSUPPORT 

53.  <OPORD :  SER VICESUPPORT 

54.  rdf:resource="http://swe.nps.edu/BMDS/OPORD 

55.  /opord20080 1 29/ServiceSupporf ’> 

56.  </OPORD :  SERVICESUPPORT> 

//The  fifth  of  the  minimum  essetial  elements  of  the 
five 

//Paragraph  operations  order; 

COMMAND  ANDSIGNAL 

57.  <OPORD : CMDSIGNAL 

58.  rdf:resource- 'http://swe.nps.edu/BMDS/OPORD 

59.  /opord20080129/CommandSignal"> 

60.  </OPORD : CMDSIGNAL> 

61.  <OPORD:CDRSNAMERANK>COOKGEN 

62.  </OPORD :  CDRSN AMERANK> 

63.  <OPORD :  AUTHENN AMEPOS>PULF ORD2IC 

64.  </OPORD: AUTHENN AMEPOS> 

//ANNEXES  A-Z  OF  THE  OPORD  EACH  IS  A  RDF 
//RESOURCE  WHOS  DESCRIPTION  IS  FOUND 
AT 

//THE  APPROPRIATE  URI 

65.  OPORD  :ANNEXES> 

66.  <rdf:Seq> 

67.  <rdf:li 

rdf:resource- 'http://swe.nps.edu/BMDS/OP 
ORD 

68.  /opord20080129/AnnexATaskO"></rdf:li> 

69.  ...<rdf:li 

rdf:resource- 'http://swe.nps.edu/BMDS/OP 
ORD 

70.  /opord20080129/AnnexZDistro"x/rdf:li> 

71.  </rdf:Seq> 

72.  </OPORD:ANNEXES> 

73.  <OPORD:DISTROrdf:resource- 'http://swe.nps.edu 

74.  /BMDS/OPORD/opord20080129/AnnexZDistro"> 

75.  </OPORD:DISTRO> 

76.  </rdf:Description> 

</rdf:RDF> 


Table  7:  Operations  Order 


4  BPEL  Orchestration  of  BM 

In  this  section,  we  specify  the  TCA  using  BPEL  [10], 
where  the  TCA  Assign  Weapon  Process  invokes  necessary 
local  and  remote  services.  In  Table  8,  TCA  is  activated 
upon  receiving  an  initialization  message,  which  includes 
an  operations  order  shown  in  Table  7,  from  the  RCA,  to 
establish  the  organizational  structure  thereby  creating  the 
chain  of  command  for  the  SCA,  RCA,  TCA  and  weapons 
and  sensors  nets.  Once  the  TCA  process  completes 
initialization  it  blocks  waiting  for  one  of  the  predefined 
messages  detect,  track,  assign  weapon,  engage,  assess  kill, 
cancel  launch,  switch  mode,  or  other  commands  from  its 
RCA.  In  our  scenario  TCA21  receives  the  assign  weapon 
message  from  RCA2  line  numbers  47-49  of  Table  8. 

As  specified  in  lines  50-67,  in  response  to  an  assign 
weapon  message,  the  TCA  invokes  a  local  monitoring 
service,  to  record  information  on  the  executing  services 
and  the  assign  weapons  task  in  its  entirety  and  the  remote 
target  weapon  pairing  (RTWP)  service  algorithm.  At  line 
110  the  process  invokes  a  local  synchronous  Local  Target 
Weapon  Pairing  (LTWP).  This  service  acts  as  a  shadow 
[1 1]  to  the  RTWP  service. 

If  the  assign  weapon  process  does  not  receive  a  result  from 
the  RTWP  within  10  seconds,  an  alarm  is  triggered  in  line 
40  alerting  the  process  to  use  the  result  from  the  LTWP 
service  for  the  rest  of  the  task. 

Upon  receiving  the  TWP  result  the  process  invokes  the 
Engage  task  line  148  with  the  result  and  waits  10  seconds 
for  a  callback,  line  156,  signaling  that  the  engage  task  has 
been  initiated  after  which  the  process  invokes  the  stop 
monitor  and  records  the  QoS,  MOP,  and  MOE  results. 
Finally,  if  the  process  does  not  receive  the  callback 
message  from  the  engage  task  it  invokes  the  warning 
callback  line  136  to  the  calling  client  signaling  that  the 
task  completed,  but  there  is  no  evidence  that  the  engage 
task  received  the  results  or  has  begun  execution. 

1.  <?xml  version="1.0"  encoding="UTF-8"?> 

2.  <:process 

3.  xmlns:AW="http://swe.nps.edu/bmds/services/AW" 

4.  :ENG="http://swe.nps.edu/bmds/services/ENGAGE" 

5.  ... 

6.  <import  importType- 'http://schemas.xmlsoap.org/wsdl/' 
location-' WSDL/ A  wMonitor.wsdl" 
ns="http://swe.nps.edu/BMDS/service/awonitor/"> 

7 .  ...  <partnerLinks> 

8.  <:partnerLink  myRole= 

9.  "awService"  name- ’assignWeapon" 
partnerLinkType- '  AW:awLT" 
partnerRole="AwCustomer'7> 

10.  . .  .</ :partnerLinks> 

11.  <:variables> 

12.  <:variable  messageType="AW:AWMsg" 
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name- 'AWMsg'7> 

13.  variables> 

14.  <:flow> 

15.  <:links> 

16.  ...</:links> 

//  lines  17-19  Receive  Assign  Weapon  from  RCA2 
//  execute  the  targetWeaponPairing  operation 

17.  <:receive  createlnstance- 'yes" 

1 8 .  name- 'Receive AWMsg" 

1 9 .  operation-'targetW eaponP airing" 
partnerLink- 'assignWeapon" 

portType-' AW:assignWeaponPT"  variable="AWMsg"> 

20.  <:sources> 

21.  <:source  linkName="L3"/> 

22.  </:sources> 

23.  </:receive> 

24.  <:pick  name="PickLocalOrRemoteResult"> 

25.  <:targets> 

26.  <: target  linkName- 'L9'7> 

27.  </:targets> 

28.  <:sources> 

29.  <:source  linkName="L4"/> 

30.  </:sources> 

//  line  31-35  if  receive  the  callback  message  assign  the 
//  results  to  engageMsgl 

31.  <:onMessage  operation-' TwpCallback" 
partnerLink="remoteTwpLT" 
portType="rtwp:TwpCallbackPT" 
variable="remoteTwpResponseMessage"> 

32.  <:assign  name- 'AssignRemoteTWPResult"> 

33.  <:copy> 

34.  <:from  part="result" 
variable="remoteTwpResponseMessage"/> 

35.  <:to  part="awResult"  variable- 'engageMsgl'7> 

36.  </:copy> 

37.  </:assign> 

38.  </:onMessage> 

39.  <:onAlarm> 

40.  <:for>PT10S</:for> 

41.  <:assign  name- 'AssignLocalTWPResult"> 

42.  <:copy> 

43.  <:from  part="result" 

44.  variable="localTWPResponseMessage"/> 

45.  <:to  part="awResult"  variable="engageMsgl"/> 

46.  </:copy> 

47.  </:assign> 

48.  </:onAlarm> 

49.  </:pick> 

//  lines  50-67  CONCURENTLY  Call  the  remote  target 
//  weapon  pairing  algorithms  and  the  moitoring  service 

50.  <:flow  name- 'FlowStartMon_RemoteTWP"> 

51.  <:targets> 

52.  <:target  linkName="L3"/> 

53.  </:targets> 

54.  <:sources> 

55.  <:source  linkName="L5'7> 

56.  </:sources> 


57.  <:links> 

58.  Clink  name="Ll'7> 

59.  Clink  name="L2"/> 

60.  </:links> 

61.  Cinvoke  inputVariable="startMonitorRequestMessage" 
name- 'InvokeAWMonitorService" 

operation-' startMonitor"  partnerLink="monitorLT" 
portType="awmon:startMonitorPT"> 

62.  <:targets> 

63.  Ctarget  linkName- 'Ll'7> 

64.  </:targets> 

65.  </:invoke> 

66.  < : invoke  inputV ariable-'remoteT wpRequestMessage" 
name- 'InvokeRemoteTWP"  operation-' Twp" 
partnerLink="remoteTwpLT" 
portType="rtwp:remoteTwprequestPT"> 

67.  <:targets> 

68.  <: target  linkName-' L2'7> 

69.  </:targets> 

70.  </:invoke> 

71.  <:  assign  name="AssignMonitorParams"> 

72.  <:sources> 

73.  <: source  linkName- 'Ll'7> 

74.  </:sources> 

75.  <:copy> 

76.  <:from> 

77.  <:literal>start</:literal> 

78.  </:from> 

79.  <:to  part="start" 

variable="remoteTwpRequestMessage'7> 

80.  </:copy> 

81.  </:assign> 

82.  <: assign  name="PassTrackList"> 

83.  <:sources> 

84.  <:source  linkName="L2"/> 

85.  </:sources> 

86.  <:copy> 

87.  <:from> 

88.  <:  literal>tracklist</ : literal> 

89.  </:from> 

90.  <:to  part="start" 

9 1 .  variable="remoteTwpRequestMessage"/> 

92.  </:copy> 

93.  </:assign> 

94.  </:flow> 

95.  <: sequence  name="SequenceLocalTWP"> 

96.  <:targets> 

97.  Ctarget  linkName="L5"/> 

98.  </:targets> 

99.  <:sources> 

100. <:source  linkName- 'L6'7> 

101. </:sources> 

102  .  < :  assign  name="PassTrackList"> 

103. <:copy> 

104. <:from> 

1 0  5 .  < :  literal>start</ :  literal> 

106.</:from> 
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107. <:to  part- ’start"  variable- ’localTWPRequestMessage’7> 

108. </:copy> 

109. </:assign> 

//  line  110  synchronous  call  to  the  local  target  weapon 
//  paring  algorithm 

110  . < : invoke  inputV ariable- ’localTWPRequestMessage" 
name=’TnvokeLocalTWP"  operation- ’localTWP" 
outputVariable- ’localTWPResponseMessage" 
partnerLink="localTWPLT" 

1 1 1  .portType="ltwp:localTWPPT’7> 

112. </:sequence> 

1 13. <:pick  name- ’Wait  10SecForCallback"> 

114. <:targets> 

1 15. <:target  linkName="L8’7> 

116. </:targets> 

//  line  117  waiting  for  callback  from  the  Engage  task  that 
//  is  invoked  after  Assign  weapon  completes  its  task. 

117  .  < :  onMessage  operation- ’ callback" 
partnerLink- ’Engage" 
portType="ENG:engageCallBackPT" 
variable="callBackMsg"> 

1 18. <:flow> 

1 19. <:links> 

120. <:link  name="L107> 

121. </:links> 

//  line  122  -  127  Stop  the  monitor  and  record  the  results 

1 22 .  < :  invoke  inputV  ariable-’  stopMonitorRequestMessage" 
name- ’InvokeStopMonitor"  operation- ’stopMonitor" 
partnerLink="StopMonitorLT" 
portType=’’awmon:stopMonitorPT"> 

123. <:sources> 

124. <:source  linkName- ’Ll  0'7> 

125. </:sources> 

126. </:invoke> 

127. <:receive  name- ’RecordMonitorResponseResults" 
operation- ’monitorCallback"  partnerLink- ’monitorLT" 
portType=’’awmon:monitorCallbackPT" 
variable=’’monitorResponseMessage’’> 

128. <:targets> 

129. <:target  linkName- ’Ll  0"/> 

130. </:targets> 

131. </:receive> 

132. </:flow> 

133.  </:  onMessage> 

134  .<:onAlarm> 

1 3  5  .<:until>P  1 0S</:until> 

//  line  136  invokes  callback  alerting  the  client  that  while 
//  assign  weapon  completed  its  task  it  has  not  received 
//  confirmation  from  the  engage  task 

136  .  < :  invoke  inputV  ariable- ’ W  arningMsg" 
name=’’InvokeW  arningCallback" 

137.  operation- ’ warningCallback" 
partnerLink- ’assignWeapon" 
portType- ’  AW :  WarningPT’’/> 

138. </:onAlarm> 

139. </:pick> 

//  Line  140  Receive  the  results  from  the  remote  target 


//  weapon  pairing  algorithm 

1 40 .  < : receive  name- ’ReceiveRemoteT WPcallback" 
operation- ’TwpCallback"  partnerLink- ’remoteTwpLT" 
portType=’’rtwp:TwpCallbackPT" 
variable=’’remoteTwpResponseMessage’’> 

141. <:targets> 

142. <:target  linkName- ’L6"/> 

143. </:targets> 

144. <:sources> 

1 45.  <: source  linkName- ’L9"/> 

146. </:sources> 

147. </:receive> 

//  line  148  invoke  the  Engage  task  of  the  kill  chain 

148  .<:invoke  inputVariable=’’engageMsgl " 
name- ’InvokeEngage"  operation- ’engage" 
partnerLink="Engage"  portType- ’ENG:engagePT’’> 

149. <:targets> 

150. <:target  linkName=’’L4’7> 

151. </:targets> 

152. <:sources> 

153. <:source  linkName- ’L7"/> 

154. </:sources> 

155. </:invoke> 

//156  receive  a  callback  from  the  engage  task  alerting  the 
//  client  that  task  handoff  is  complete 

1 56. <:receive  name- ’ReceiveEngageCallback" 
operation- ’callback"  partnerLink- ’Engage" 
portType- ’ENG:engageCallBackPT" 
variable- ’callBackMsg’’> 

157. <:targets> 

158. <:target  linkName- ’L7'7> 

159. </:targets> 

160. <:sources> 

161. <:source  linkName- ’L8"/> 

162. </:sources> 

163. </:receive> 

164. </:flow> 

165. </:process> 

Table  8  The  TCA  Process 

5  Evolution  of  OPORDS 

As  discussed  in  Section  3.3  above  the  OPORD  provides 
the  Mission  of  two  higher  levels  of  command  and  tasks  to 
subordinates.  Once  the  initial  order  is  received  the 
commander  must  delete  the  higher  level  commands 
mission  and  add  his  own.  In  addition,  the  commander 
must  remove  the  tasks  to  the  subordinates  and  provide 
tasks  to  his  subordinates.  Typical  information  in  the  tasks 
might  be  things  such  as  the  defended  sector  assignment 
and  orientation  of  weapons  systems  and  asset  to  be 
defended  in  sector  (e.g.  from  the  PDAL). 

The  initial  OPORD  would  have  been  sent  during 
initialization  prior  to  any  of  the  messages  received  in  Table 
8  above.  However,  in  our  scenario  the  threat  ballistic 
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missiles  do  not  attack  according  to  the  intelligence 
estimate  sent  out  in  the  initial  OPORD  and  RCA  issues  a 
FRAGMENTARY  ORDER  (FRAGO)  as  part  of  the 
AssignWeaponMsg  to  its  subordinate  TCAs  to  be  prepared 
to  reorient  weapons  systems  and  sensors  in  line  17.  The 
AssignWeaponMSG  would  contain  those  parts  of  the 
OPORD  that  had  change;  for  instance  the  mission  is  the 
same,  but  the  execution  paragraph  would  task  sensors  and 
weapons  to  reorient  in  the  general  direction  of  the 
incoming  target  so  that  the  weapons  systems  could  engage 
at  the  earliest  opportunity. 

6  Conclusions 

We  show  how  the  BPEL  with  appropriate  extensions  for 
MoPs,  MoEs  and  QoS  parameters  can  be  used  to  specify 
command,  control,  and  battle  management  needs  of 
Ballistic  Missile  Control.  In  follow  on  work  we  intend  on 
showing  a  much  more  rigorous  and  complete  design  of  the 
BM  for  the  scenario  proposed  in  this  paper. 
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